5 ms·

I hope you realize that you are arguing against an explicitly subjective statement. Nevertheless, please elaborate. What do YOU think is the difference here be

• kazinator 10y ago
  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.html#tag_20_152_13_21 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
  • JepZ 10y ago
    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.
• lispm 10y ago
  > 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.