

Why Lisp? - octopus
http://lisperator.net/blog/why-lisp/

======
zalew
> _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
Or, you know, cscope?

------
dschiptsov
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.)

------
lucian1900
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.

~~~
vseloved
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-2
Common Lisp is Lisp.

Racket is Scheme.

Scheme is Lisp.

SBCL is Common Lisp.

~~~
vseloved
Let's translate it to C:

C99 is C.

C++0x is C++.

C++ is C.

Clang is C99.

Do all the lines seem correct?

~~~
qu4z-2
I disagree with your translation. I admit that "SBCL is Common Lisp" is a
stretch, but no more than your original "Racket is Scheme". How about instead:

LISP 1.5 is like C

Common Lisp is like C++

Scheme is like Objective-C

(ignoring all the other Lisp dialects that have fallen by the wayside:
Maclisp, Interlisp, ZetaLisp)

~~~
vseloved
Here's a more detailed answer: [http://lisp-univ-
etc.blogspot.com/2013/01/common-lisp-is-jus...](http://lisp-univ-
etc.blogspot.com/2013/01/common-lisp-is-just-lisp.html)

I also agree, that Racket is not Scheme, it's a new language. But I stand,
that Common Lisp is still a Lisp. Lisp 1.5 would be BCPL or B :) (Why? Because
C is in active use, while Lisp 1.5 isn't, so your analogy isn't quite correct)

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

~~~
octopus
Today you have 3 main alternatives:

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

* Scheme

* Clojure

~~~
qznc
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>

~~~
gnosis
I think Chicken[1] is a very attractive Scheme alternative. It's full-
featured, fast, compiles down to C, has a very nice library (egg) system, and
a relatively large and active user community (as far as Schemes go).

[1] - <http://call-cc.org/>

~~~
klutometis
Hear, hear; I've been using Chicken for commercial and personal projects for
about five years now. It keeps getting better.

Occasionally, Racket has a package that I'd like to port (e.g. datalog); but I
find it otherwise overbearing.

Chicken has found some local maximum of efficiency and availability of useful
libraries.

------
xradionut
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... )

~~~
vseloved
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
;)

------
martinced
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
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...](http://michaelochurch.wordpress.com/2013/01/09/ide-culture-vs-
unix-philosophy/) (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.

~~~
blablabla123
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.

~~~
anon1385
>Massive build instructions […] would never happen when using a plain editor.

How many non trivial projects do you compile by hand rather than using an
automated build system (make etc)? How does autoconf or cmake prevent or
discourage you from using 'massive build instructions'? Why is turning on more
warnings or other compiler options a bad thing?

>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.

You are talking about code-completion. What 'regular editor' do you use that
doesn't have at least basic support for code-completion? pico/nano? Notepad?

When these arguments/rants come up, it seems that the definition of 'IDE'
changes to fit the argument being made. If somebody suggests they prefer to
use an IDE because it has code-completion, they are quickly told that plain
editor X also has code-completion. Then it is argued that IDEs are bad because
they have code-completion which encourages you to write verbose code. This
seems to extend to many other 'IDE' features: I've seen people argue against
inline documentation lookup, against syntax highlighting, against a 'build' or
compile command in the editor, against 'jump to definition', against
interactive debuggers. I've also seen people argue that all those things are
available in 'plain editors' and thus there is no need to use an IDE to get
them.

At this point I've no idea at all what the difference is between an IDE and
'plain editor'. Other than truly basic editors that hardly anybody uses to
code, I think just about everything could be called an IDE.

~~~
jiggy2011
Agreed, my workflow is basically the same whether I use an editor or IDE.

The only difference being that sometimes I wish the editor had more features
and sometimes I wish the IDE had less stuff on the screen so I could just see
the code.

It is however a lot easier to configure an IDE into a dumb editor than it is
the other way around.

