All Turing-complete languages are equivalent and can solve the same set of problems. The issue is not whether you can or can't do it, but how much work it will take and how painful the process will be.
Also when you learn some Lisp, you start to realize how often people are greenspuning[0] things in their projects.
I don't think there are very many "real world" problems that you CAN solve in Lisp, and CANNOT solve in Python. Anything [0] you can write in Python, you can likely solve in Lisp, probably in similar line count (without macros).
One thing I __really__ miss from working in lisp is the idea that I can reload things in the repl. In Python, once I've imported something, I can't really redefine it without pasting in the definition, which makes iterating on a class definition much harder. In Lisp, I can hit a key in my editor and the running REPL gets the new definition, and I can start working with it (or rewriting tests, etc).
The power of the REPL in lisp is __amazing__. I love me some IPython (it's awesome), but there just isn't the same tight integration between that and a running system. The "default" Python likely has all the tools you need to do that, but it just isn't presented as the Way you Do It.
Django's auto-reload when code changes is an example of this. The trouble is, I can't get to a REPL easily within that, without invoking ipdb. I don't know how to integrate my editor with the Python process in a similar way, etc.
All that said, I still love coding in Python. Hy makes me excited, but then I just started writing python-with-parens and wasn't sure what I had gained. :)
0: I'm sure there is someone who can give a counterexample, but I cannot thnk of any.
Thanks a TON! I am Frequently Slightly Annoyed by pressing control-. and having to re-import things, declare things, etc. I'm looking forward to using this.
I reload things in ipython all the time, just do an execfile (and maybe be sure to define __name__ to something besides '__main__' so it doesn't trigger the usual checks).
The sage version, and maybe this is backported to ipython by now, I don't know, you can do an %attach on a file and it gets reloaded into the workspace every time it changes.
The best you'll get are examples of something solvable in Python being "beautiful" in Lisp. Then some real world Lisp examples will be references to a 20 year old storefront generator and the initial release of reddit.
Lisp(s) are certainly better than Python in every way, except when it comes to successful projects completed.
I think you need a bigger reference frame of Lisp's usage over its 50 year history that extends even to 2015. But even then, quoting Kent Pitman: "Please don't assume Lisp is only useful for Animation and Graphics, AI, Bioinformatics, B2B and E-Commerce, Data Mining, EDA/Semiconductor applications, Expert Systems, Finance, Intelligent Agents, Knowledge Management, Mechanical CAD, Modeling and Simulation, Natural Language, Optimization, Research, Risk Analysis, Scheduling, Telecom, and Web Authoring just because these are the only things they happened to list." (My additions are video games and Mars rovers.)
Part of the visibility issue is that there are very few big-name open source Common Lisp success stories which aren't CL implementations, or CL ecosystem tools. Most of the things in that list are big-ticket enterprisey applications.
Lisp's Eclipse is called GNU Emacs and it's free software. It comes with more than a million lines of Lisp code supporting all kinds of development tasks.
It's also not Common Lisp. I get that emacs lisp is a pretty good example of a lisp, but I do find it interesting that the Lisp designed to be the widely-applicable industry standard hasn't seen something on the same level.
> So what's stopped these from getting to Emacs' level of popularity?
Emacs is not an editor. Emacs is a family of editors. You are probably talking about GNU Emacs.
They never tried and it would not make sense. GNU Emacs exists already and supports Lisp development very well. The other tools have concentrated on other things: GUI-based IDEs for Lisp.
> Emacs is not an editor. Emacs is a family of editors. You are probably talking about GNU Emacs.
You tell me, you brought it up!
> They never tried and it would not make sense. GNU Emacs exists already and supports Lisp development very well. The other tools have concentrated on other things: GUI-based IDEs for Lisp.
Emacs is for more than Lisp development, though. It's not popular because you can do Lisp in it, it's popular because you can do everything in it. So we're back to my earlier question, which is why we haven't seen major, broad-based wins for Common Lisp, on the scale that we have for other languages.
> Emacs is for more than Lisp development, though.
Not Emacs, GNU Emacs. That's what I wrote.
> we haven't seen major, broad-based wins for Common Lisp, on the scale that we have for other languages.
Common Lisp tends to be used in very specialized areas. It's a complex language.
Though sometimes it has been used where you don't see it, but you may be affected. American Express runs a Lisp based system checking credit card transactions. Should be running for two decades or longer. Amazon was using Lisp to compute some stuff on their shopping pages. CIA and NSA use it to spy on us. Lots of aircrafts (Airbus & Boeing) and cars (Jaguar, Ford, ...) were designed with Lisp-based CAD systems. NASA uses it for checking software correctness. Chip makers like AMD have used it to check processor designs for correct operations. There are many of those applications. Google's flight search engine has its core written in Lisp. Dwave wrote the software for their quantum processor in Lisp. There is a broadband internet of satellite company running Lisp on their antennas. Parts of the precursor software of Apple's Siri were written in Lisp. That's the stuff what it was originally was designed for...
Any real world problem solved in Lisp, relative to being solved in Python, eliminates the superfluous problem of Python being involved: a syntactically Fortran-like cumbersome scripting language with somewhat Lispy semantics.
Note that you can program the CL system by expressing yourself in Python:
Common Lisp is not only a language, but also a platform (analogous to Mono or JVMs). It has a model of computation: programs expand fully down to a set of special forms, which then compile. You can build languages on top of this.
I'm not quite sure how being able to extend syntax is a theoretical problem. It was just a basic example for brevity.
There are many more examples of macros that solve real world problems, such as writing a compiler for an embedded DSL that is tuned to solving your real problem that allows expressivity and brevity that you would never see without the use of macros.
