Some of us just like to have infinite scrollback buffer, rectangle select, bookmarks, regular expression replace, in our remote shells. And all our other customizations.

Emacs isn't the be-all end-all tool (it doesn't run on the JVM for starters). But it is one interface to rule them all, and the interface is extensible at runtime. You can install a few packages and have a Java IDE running inside the interface. Or a version control system.

It's not that you have to... but you invested enough effort in making your interface powerful. You want to do more inside of it.

I don't actually feel as strongly as this comment might sound -- use what you want to use -- but I wanted to get a dig in :-)

When I used emacs extensively (in viper mode, before Vim really was popular and good vi alternatives with filename completion existed), it really blew as a text editor without viper, and all the customizations never really worked well with one another. (Viper didn't work with anything else, typically).

In particular, the shell mode you refer to was just awful. Most of the time it would get confused by what came out of the pty -- lord help you if you happened to echo the wrong thing (e.g. binary data) by accident to the terminal.

Meanwhile, scrollback/rect select are basic features of any terminal emulator (or gnu screen), and re-replace/bookmarks in the history is a basic feature of modern shells.

I'm not sure if we're talking about the same terminal.

M-x term is a terminal emulator that acts like xterm and obscures all the great emacs stuff. I think that thing blows.

M-x shell is a fully-featured shell that also happens to be a normal buffer. When you cat binary data to it, it just displays binary data (as control characters, most often). I usually have to use quote (C-q) to, for instance, send a KILL to the running process (C-q C-c RET). On the bright side, if I change my mind, I just delete the C-c before I hit RET and type something else.

I'm not just talking about re-replace in history (although yes it has that, along with M-/ (for me, hippie-expand) to complete with arbitrary text from any open buffer in Emacs).

I am talking about manipulating the input/output by just editing junk in the buffer. For instance, I get 10000 lines of output and just clean it up or select a region, then run a ten-line function I wrote in elisp to do some calculation on the data, in the shell buffer, without copying it anywhere else or otherwise disrupting my flow. And I never have to touch my mouse to do it.

This is the real promise, that any useful integration you do for one part of Emacs applies to every part of it, without having to learn a new set of bindings or the weird indirections you get out of combining screen plus the terminal plus the command line sql interface plus... And there are many many useful libraries that have come out over the years.

That's like saying 'when I used a 747 to drive to the corner store...'

Vim eats 8-10M of my memory. Emacs with many different modes running eats 15-20M. It mattered back in 1996 when I've had 24M of RAM, heck I remember programming in emacs + X11 having as low as 16M and I survived ;)

But to the point. The difference between 10 and 20M doesn't matter anymore.

What matters is that Eclipse eats 500M of memory, is sluggish and I doubt it offers better programming experience; still so many people don't want to listen that there are alternatives to it.

I think that's the area we should debate & educate people. Both vi/emacs are brilliantly light these days.

Axiom was sold commercially, before it was open sourced.

Axiom is also not written in one language. It is really the opposite. Lisp is basically the runtime for a complex domain specific language for mathematics. It is in some ways similar to Haskell. The language allows, how can I say it, a structuring of the mathematical domains with a typed language. Probably one of the most advanced pieces of software in that area.

The capabilities of Axiom are really amazing.

But I feel my comment still holds; Axiom is obviously a piece of research software with a research interface (e.g. a programming language as an interface) that was developed to help people do research.

It is not a typical example of software in "industry" where "industry" is implied by the OP to be software in a general sense over many domains. But perhaps the argument is weaker than that...

Anyway, I don't have enough of a stake in this to argue. But I do think the characterization of lisp as something that is suitable for "industry-blub" is inaccurate. I don't subscribe to the view that there's this strict hierarchy from lisp down to blub. Rather, Lisp is a prototyping and template language, and in products, shows up in areas where the product itself is continually a prototype. Research software fits this bill, as does the scripting interface to a larger product.

pg thinks rapidly changing web apps fit the bill -- I think that might actually be true in the early stages, and less so later on. That seems to be where the evidence points, at least.

Axiom went through a period of research, but was commercially released and maintained for several years. It is now around 40 years old.

I would agree that Lisp is not that suitable to industry in general.

Lisp has been developed to do symbolic computation. Computer algebra systems fall into this category. These have applications in physics and many other domains. You would need to scan the large bibliography of some of these systems to find all the application domains. Remember Mathematica is commercially sold and widely used. Axiom fall into this category.

Lisp can be naturally used in all the domains where one computes with all kinds of symbolic data and languages. Another typical example are microprocessors. Lisp has been applied to check the correctness of various operations (floating point, ...) of AMD processors. This is not 'research', but part of the testing of chip designs. The chip design will be described in some language and some software will prove that the operations are correct based on a set of requirements.

These are natural Lisp applications and they have nothing to do with research, prototyping or templating. They are applications of computing with symbolic expressions.

This means Lisp has a natural application domain. Though this domain may not be large or popular, it does exist and provides a reason why it still exists.

McCarthy wanted a language for certain problems. With lists, functions, symbolic expressions, evaluator, ... and more. Then he and the people he was working with stumbled across the thing that it can be applied to itself. This is why we say Lisp was not invented, but discovered. Lisp was supposed to have some kind of conventional syntax. But it was discovered that one can output the internal data that represents data and code as s-expressions. Then one saw that those can be written and read back. So the internal symbolic data suddenly had a corresponding external data representation. One that could be used for data, all kinds of data. Suddenly also Lisp programs themselves were trivially externalized data via s-expressions. Read back they could be manipulated with the usual operations that were designed for symbolic expressions.

One application of Lisp's capability to compute with symbols, is that it is applied to itself and thus provides meta-linguistic capabilities (macros are well known). This means that just as easy as you can write language for symbolic computation with mathematical formulas (for integration, differentiation, simplification, and all that stuff), just as easy one can write and extend an implementation of Lisp, since its programs are also symbolic expressions. So the capability (computation with symbolic formulas) that was developed for domains like maths, planning, scheduling, knowledge representation, theorem provers, ... can be applied to Lisp itself.

This has interesting effects and is also the reason why Lisp is especially disliked for tasks where flexibility is not needed or not wanted and programmers use a language without meta-linguistic capabilities. Lisp would require more self-discipline and in industrial projects fixed processes with fixed tools are often preferred.

The unstated question Tim Daly is answering is "Can you, as a lisper, complete projects for Industry™", and the answer is yes.

The two essays are answering two different questions, and they're both "right".

I see you associated an identity with him and then attempted to apply it in a narrow, derogatory manner, but in my exploration of Lisp and its community, I have not encountered some of his arguments before. It might be more useful in general to avoid applying silly stereotypes to people. Tim does not represent people who use Lisp.

> Open source math packages and academic software isn't > "industry". Sorry.

Strawman argument and pretty selective (perhaps because of bias?) -- he also mentioned "Google just bought a company that developed in lisp.", and just because he did not list a ton of other commercial projects out there does not invalidate his point. Your ignorance of money-making Lisp projects does not make them nonexistent.

I agree with you on the matter of libraries/modules/packages being nice. I like that CL-WHO is available to the community for language templating; that DRAKMA can help me with web browsing, cookies, and so forth. There are a lot of useful Lisp libraries out there. I am not convinced by you or others that the small number is representative of anything, given that the language seems to have a ton of nice built-ins. I have yet to fail to accomplish something I wanted to try in Lisp, and I am hardly an experienced Lisp user.

And I have run into a plethora of libraries in other languages that are almost garbage or at least not good enough for my needs. I have work to do, and people waste it by spamming me with half-wrung libraries... so many options, so few gems. The presence of tons of libraries does not make me jump for joy. I just want things that work.

Like you, I felt the author's argument was a little overboard with regards to packages, although there is a small point to it: It is easy to create some of these DSLs in Lisp, so easy that you might just roll it yourself instead of rely on some random person's library/package to do it the way that makes sense to you. On the other hand, I don't personally want to write a network graph package; I am lazy and would like a nice, commonly-used, peer-maintained solution.

But consider this, too, about CL: With CFFI/UFFI, you have easy access to any compiled library out there. If you were using C, you would import a header file to use that library. In Lisp, you write a header-file-like module to import it. Done deal. No need to reinvent the wheel. Lisp can integrate with stuff produced by other languages.

> Just because your "domain specific language" is forced to > be sexps, certainly doesn't make it superior, IMO.

What makes it superior is: It is immensely easier to do it in Lisp and with more parsing potential than lex/yacc (and what a great example of something ugly); "easier" is an opinion word, but I think if you try both approaches with a good amount of experience in both, you would see the difference. Nobody contests that other languages absolutely lack preparsers. However, Lisp continues to be worlds ahead of the crowd in terms of the integration and ease of its parsing features, and you do not have to import a third-party library in order to get them.

I suspect that fundamentally, it has to do with the language itself being like writing code in a syntax tree. Of course, Lisp provides you the ability to change this.

A second reason for this superiority -- and tackling another comment you made ("the idea that everything must be done with the same tool is a crazy idea") -- is that you do not have to use a second language in order to get that bonus. You have all the weight and power of a full-fledged language behind you to make whatever transforms you feel you need for your parsing task. And that language is the same language you are parsing. It might be hard to grasp how important this is at a glance, and again, it comes down to trying it out.

Are people saying everything MUST be done with the same tool? That sounds silly to me. I have never heard/read that. But it is certainly nice if you can, and it is within Lisp's power. Imagine writing JavaScript (PARENSCRIPT) in Lisp; suddenly you have the ability to use macros, as provided by Lisp, and you can make writing in JavaScript less annoying.

I do not care if people use Lisp, except to suggest that it is likely in your best interest -- for all domains -- to incorporate its concepts and the language itself. It is not like there is some kind of contest going on where Yegge's points, Tim's points, your points, or my points are going to choose some winner.