Why Lisp?

http://lisperator.net/blog/why-lisp/

by octopus • 14 years ago

91 69 14 years ago

lisperator.net

rman666• 14 years ago

It's not so much a question of "Why Lisp?" as it is a question of "Which Lisp?," if you ask me.

octopus2• 14 years ago

Today you have 3 main alternatives:

* Common Lisp (used by the author of the article)

* Scheme

* Clojure

sillysaurus3• 14 years ago

One thing that intrigues me about clojure is that it affords some unique benefits, by virtue of being a lisp. For fun I want to try to write a clojure program which generates C code for a tiny game engine. e.g. you run the program, and it spits out .c and .h files which you can then compile and run.

Then, the challenge is to make it generate java code, too. I.e. in addition to the C code, which you can build and run, it also generates that same functionality in Java code, which you can run on JRE. So the game engine itself would be specified in clojure, and yet it would be "automatically implemented" across two very-different platforms! It's a fun challenge, I think. Maybe not doable, or doable only in a horrible way, but still fun.

But the point is this: that's a great example of a problem which would be pretty much impossible in a non-lisp language. In order to achieve that in Python, you'd probably be forced to implement a lightweight lisp within Python.

So that may demonstrate an answer to the question, "Why Lisp?" ... certain problems can be solved only in lisp, or by reimplementing the list-processing concepts of lisp.

strobe2• 14 years ago

And, It's really hard to choose one! All of 3 dialects has own unique benefits and lacks.

qznc3• 14 years ago

Scheme is not a single alternative. Racket [0] is a Scheme, which can be compared to things like Python or Ruby. There are other implementations, which should be used for different uses. For example, Chibi Scheme [1] is a nice alternative to Lua, but not to Python or Ruby.

Given your other two Lisps, I rather make this list:

* Common Lisp (which implementation?)

* Racket

* Clojure

[0] http://racket-lang.org/ [1] http://synthcode.com/wiki/chibi-scheme

vseloved5• 14 years ago

Common Lisp. Everything else is so much Lisp as php is perl or C++ is C.

martinced• 14 years ago

I'm a big Lisp dialects proponent but I don't like that article very much.

It's very naive and the author is unexperienced IMHO.

For example the author writes: "I can place the cursor on the name of a function and ask “where is this defined”, and it jumps to the place of the definition, which could be in my own code or in third party code. But I can also ask “where is this function called” or “where is this variable referenced”. This is extremely useful for code refactoring and it beats every “modern” IDE I've seen."

Ouch.

The author doesn't seem to be very knowledgeable of "best practices" and IDEs from the last ten years available in the Java/C# world.

Lisp dialects can really shine in various ways but "refactoring" ain't exactly one area where Emacs (which he mentions and which I do love) beats "modern IDEs".

Apparently the author's only experience comes from old JavaScript development environments and some Perl hacking. He's hardly "connected" with real-word, modern, way of developing software.

His description as to how he's upgrading servers by manually copying binaries also shows he's disconnected from actual enterprise deployment techniques.

Overall it feels very amateurish.

But kudos for picking a Lisp dialect and sticking to it and reaping the benefits of that smart choice...

michaelochurch• 14 years ago

I dislike most of these "modern IDEs". They seem to encourage Big Programs that shouldn't be written in the first place. http://michaelochurch.wordpress.com/2013/01/09/ide-culture-v... (IDE culture vs. Unix philosophy).

However, you are right that, in terms of features, they deliver, if you keep your directory structure, language choice, and development practices within certain bounds.

blablabla1232• 14 years ago

Yes... I mean even if the programs are big, IDEs encourage a massive footprint of just about anything. (I would not go so far to declare big programs per se as a bad thing.) Massive build instructions, massive Interface declarations, massive amount of stub files... Things happen with IDEs that would never happen when using a plain editor.

Probably Java has a part of its verbose reputation due to the abuse of IDEs. It's just so easy to use 60 letter function names, if you used a regular editor, people would not do this because their hands would start to hurt.

qznc3• 14 years ago

The fundamental question is how we compose things. The Unix way is to compose small programs via byte streams. Another way is to link lots of libraries via function calls. Yet another way is the image approach taken by Smalltalk and Common Lisp. These approaches all have tradeoffs and their own version of the dependency hell.

Thanks to the batteries-included philosophy a few lines of python can yield power, which would be a Big Program in the early days of Unix. I assume nobody would suggest that Python's glob library should exec the find executable or something.

mark_l_watson2• 14 years ago

After a few decades of emacs and Common Lisp, I strongly prefer the free community IntelliJ with the Clojure plugin.

Sure, I have emacs setup for Clojure development, I just don't use it anymore, preferring IntelliJ. Times change :-)

blablabla1232• 14 years ago

Many people don't use IDEs anymore, I guess the only field IDEs are still dominant is the corporate environment. (And some LISP shops obviously ;)) So even if he hasn't used Visual C#, Netbeans or Eclipse yet, this doesn't necasserily mean that he is unexperienced. There is still software development going on beyond enterprise. ;)

jiggy20112• 14 years ago

I don't know, plenty of game developers, android developers and iOS developers are IDE users.

pnathan• 14 years ago

Yeah, the author obviously has never used Visual Studio (Or Eclipse or SlickEdit or...) in the last decade or so.

However, the "real world deployment" thing is kind of a spectrum. There's definitely the super-tight provisioning/deployments with ec2/puppet/jenkins/etc, but it goes all the way down to "have debian and hand-install widgets". That seems to depend on the organization's willingness to buy into the "cloud" idea, which seems to be regulated by the leadership's comfort with software.

wglb4• 14 years ago

So far as I know, Visual Studio won't show you the source code to length or read, whereas Lisp will.

KirinDave2• 14 years ago

Except many popular, monder lisps still don't show you that. Native functions often can't be shown. Bummer, huh?

eropple2• 14 years ago

You sure? I don't know if VS will by default, but (at least on my machine) it's installed under ${VS11}/VC/crt/src so I'm sure it's possible - not sure if it's the complete sources, though.

Eclipse or IntelliJ will for Java if you install the JDK, though, and I'm pretty sure you can install the libc++ sources for XCode and go through them if you want (don't quite me on that though).

zalew• 14 years ago

> This is helped by a great feature of the environment (Emacs/SLIME) which provides cross-referencing tools, for example, I can place the cursor on the name of a function and ask “where is this defined”, and it jumps to the place of the definition, which could be in my own code or in third party code. But I can also ask “where is this function called” or “where is this variable referenced”. This is extremely useful for code refactoring and it beats every “modern” IDE I've seen.

wow, rly? you have this in Eclipse (and probably every 'modern' IDE out there) for every language.

demallien• 14 years ago

Or, you know, cscope?

lucian1900• 14 years ago

Interesting that "Lisp" is assumed to be Common Lisp and that Scheme is assumed to be strictly a learning tool. I've found Racket to be much more useful than any other Common Lisp/Scheme.

gnosis2• 14 years ago

I have to agree with that. I find Scheme to be a lot cleaner, more modern, and easier to use than Common Lisp.

I really only see two reasons to choose Common Lisp over Scheme. The first is that CL has a ton of libraries compared to most Schemes (though Racket has quite a few of its own.. I'm not sure how those two would compare on the library front). The second reason is that CL has a much larger community.

vseloved5• 14 years ago

Well, Common Lisp is Lisp, Racket is Scheme, they are different. This perpetual confusion is just useless. Let's call things by their names. You don't call C++ C or php perl, right?

qu4z-22• 14 years ago

Common Lisp is Lisp.

Racket is Scheme.

Scheme is Lisp.

SBCL is Common Lisp.

dschiptsov• 14 years ago

few more slogans:

* Ruby's emphasis on writing DLS came from Lisp world, where this practice have been developed.

* Some of Python's elegant forms - with, lambda and various comprehensions - like this: return (x, y) or a = [3, 4, 5] came form Lisp.

* Lisp's macros are unmatched. Those of C/C++ are mere string substitution.

* REPL is Lisp's invention.

* Shadowing (re-binding) of variables and procedures used routinely - we don't need any special "dependency injection".

* Logically, everything is a pointer, so, technically, every "object" if a first-class citizen.

* Lisp is mostly-functional, so, in cases where you must have mutation, you just do it.

Enough for today.) Over-excitement is a vulnerability.)

xradionut• 14 years ago

There's only a few reasons to use Lisp. It's educational from a math/comp-sci aspect, you enjoy programming in it, and you can make money doing so. Career wise, it's way down on the list of languages/environments in which I would choose to do my daily coding. (And I don't currently have my brother-in-law calling me on a weekly basis to assist in automating various tasks in AutoLisp... )

outworlder• 14 years ago

If your only source of Lisp exposure is AutoLisp, that would explain the dislike.

AutoLisp is very primitive even when compared with minimalist Scheme interpreters.

vseloved5• 14 years ago

There are more reasons to use Lisp actually: the biggest one of which is, probably, that many programs become much simpler in it.

But, actually, such argument is meaningless. The only meaningful argument would be to compare the pros and cons of using Lisp versus some other language for a specific field with some specific constraints.

For instance, I won't be trying to use Lisp over JavaScript for writing Firefox plugins, but, probably I would use it over Objective C for this task ;)

Why Lisp?

Related Stories