Even original Vi from AT&T Unix (never mind Vim) better supports outside parentheses:

If the cursor is here

   (foo bar)
           ^

I can cut the whole thing using just d%: combine d)eletion with the % cursor movement (jump to opposite parenthesis). Then you can paste it elsewhere with p.

It's a POSIX-standard feature: see here: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi...

That's just a crap editor for sysadmin tasks I wouldn't use for development.

If the syntax is:

   foo(bar)
          ^

then we jump only over the argument list, not the whole expression.

Another thing is the damned comma disesase in f(x, y) languages. Say we are in Vi:

   (foo abc def ghi)
           ^

We want to swap the last two parameters. Easy: type deep. Done! d)elete to e)nd of word, go to e)nd of word, p)aste.

Now try it with

   foo(abc, def, ghi)
           ^

Annoying!

Imagine if your operating system shell forced you to use commas between command line arguments. Nobody would use such an idiotic thing. Why do we put up with languages that do that?

    $ ls, -l, *.foo  # just kill me now

Move second argument to third position: "parens outside" together with "no commas between arguments" makes it a breeze:

    (foo (a b c) (d e f) (g h i) (j k))
                ^

Instead of deep we just do d%%p. Done.

    (foo (a b c) (g h i) (j k))
                ^ d%

    (foo (a b c) (g h i) (j k))
                       ^ d%%


    (foo (a b c) (g h i) (d e f) (j k))
                               ^ d%%p

Thank you very much for your explanation, I see your point.

I think I will still prefer the C style for parenthesis (as I would care more for the LOOK than for the FEEL ;-), but regarding the commas, I agree that skipping them would make the life a easier. I mean besides lisp and bash/shell other languages have done so too (e.g. Smalltalk) and spaces aren't allowed anyway inside parameter names.

> I hope you realize that you are arguing against an explicitly subjective statement.

Yes.

> Nevertheless, please elaborate. What do YOU think is the difference here between feeling and looking? Do you mean that your favorite editor (or the majority of editors) better supports outside parenthesis?

Lisp has a two-level syntax. The first level is the syntax of s-expressions. On top of s-expressions we have the actual Lisp syntax.

S-expressions have a few features:

  * it's a data syntax for lists/trees, numbers, characters, symbols, strings, ...
  * delimiter surround the data, it is always clear where the expression begins and where it ends
  * whitespace is used to delimit the elements
  * s-expressions are not sensitive to lines and whitespace
  * s-expressions can be automatically formatted by simple rules, according to different widths
  * the tree structure is explicit, not implicit. It is visible, based on the s-expression nesting.

For an s-expression editor it makes not much difference to edit a data list like ((berlin germany) (rome italy) (paris france)) or code like (defun collide (object wall) ...) .

The first level of editor support you get for editing s-expressions.

Thus editing on this level FEELS like you manipulate data: create, transpose, delete, list, de-list, flatten, copy, indent, format, ...

That every list has explicit delimiters makes clear where the expression begins, where it ends and what its contents are. The parentheses also serve as 'handles' for the thing. If you use some more advanced Lisp system, the s-expression creates a region and moving the cursor into this region enables context sensitive commands. This is possible in other systems, too. But here the relationship between the s-expression and the region is visually clear: each expression has explicit delimiters, front and end.

So, the first level of Lisp editing is data manipulation. That's a big difference to editing many other languages, where your program is not also a simple data-structure. There you are always on a language level, maybe on a primitive token-scanner level. You can reconstruct the tree structure, but it is not visible, explicit and delimiting like in Lisp. If you refactor a program, you work on the programming level - in Lisp you can work on a plain data level, too. This makes code and data interchangeable and when you work with a Lisp listener (running a read eval print loop), you will work with code as data and the listener helps you: you get support on the language level & the s-expression level on the editor side. But at the same time you can cross the the border into the programming language: you can let Lisp manipulate your program. Thus programming becomes a mix of manipulating text and data. The s-expression syntax helps to make that simple - because of the features above.

A typical example would be writing a macro (Lisp code which transforms code) based on some existing expressions. You would take the expressions, convert them into data, create the transformation code, define the macro. Then you would test the code generator. Thus suddenly from writing code, you switch to writing code-writing-code and the input and output is no longer data, but code as data. Thus while programming you will interact with the code generator. This can be done in many languages, but in Lisp it FEELS different, because you work on s-expressions - easily delimited hierarchical pieces of code as data, which can be transformed by your editor and your underlying Lisp system.

After a while, editing conventional code FEELS less direct. It feels like you manipulate the code with instruments, while a good Lisp system feels direct. That's it direct manipulation of code and data.

A Lisp programming will learn this code manipulation side and then is willing to give up some looks for that. Originally Lisp had a more traditional surface syntax, but it turned out to be more practical to use the s-expression based code representation not only internally, but also using it externally on the display or textual side.

Is there any good starting point to use lisp in the same way as I would use go? I mean I write web servers and command line tools in go. As an editor I use vim.

Some time ago I used DrScheme (now Racket) to write Scheme but I never found it to fit easily into my workflow/use-cases.

So I would I like to use the language with the following workflow (100% terminal):

- write code with vim: vim main.lisp - simply compile the code to binary: lisp build main.lisp - execute the compiled program: ./main

Any ideas?

I wouldn't propose to do it in Lisp. Batch programming is done better in languages like Go, especially if you are already feeling comfortable with a batch workflow. You can write web servers and command line tools in Lisp, but it would be a huge investment to learn that and it is not clear if it pays back for you.

Essentially for anything slightly complex one would use an interactive programming style and 'only' deliver the application in a batch style.

Racket is more oriented towards batch programming, compared to popular Common Lisp development environments.

Lisp is terrific for batch programming (too).

You can edit a Lisp program strictly in files, and run a build step to produce a clean image which is tested, using a REPL just as a debugger, to "go in" and find out what is wrong.

If he uses a REPL, it is no longer batch programming. The plain edit/compile/run cycle is best left to other languages.

Ok, so the definition of batch programming means that debugging is only allowed by print statements (or other side effects from which we infer what happened in an actual run of the program and work backwards). For instance, using a breakpoint debugger on C isn't batch.

Still, Lisp is good for that. I've debugged Lisp programs with print statements and it was at least as good an experience as debugging programs in other languages using print statements.

For instance, if we compare to C, C has no trace, and generally no easy way to wrap any function with a wrapper that takes the arguments. Ecosystems built around C, like the Linux kernel, have developed things like that: Linux has a function tracing thing in it (more than one, I think).