History of Lisp Editing
github.com
github.com
I think ITS Emacs (written in TECO) had paren matching before the CADR Lisp machines (what you call Zmacs, but it was EINE originally).
The first Emacs written in Lisp was Multics Emacs (written by Bernie Greenberg) and it had paren matching when I used it but that was 81/82 timeframe.
What do you call paren matching by the way? Emacs always had structure navigation (c-m-F/B and c-m-U etc) in which case that support went back into the 1970s.
(BTW the first Emacs-like editor for the lispms was EINE (Eine Is Not Emacs); it was replaced by ZWEI (Zwei Was Eine Initially). Look at a German dictionary if that is not funny. IIRC Zmacs was a renaming by Symbolics as part of their efforts to move beyond the AI lab implementation (While LMI/TI continued to sync back to the AI lab sources).
ETA: are you sure about the timeline? I thought Multics Emacs was something of a reaction to EINE/ZWEI -- I seem to recall that Bernie didn't like the fact that all the editing primitives required an explicit point argument; he made point implicit, a design decision that was copied in Gosling Emacs. Well, that's my recollection anyway.
> Debating Maclisp vs Interlisp (i.e. storing code as text vs structure)
This really puts "tabs vs. spaces" to shame.
As we continue wishing we had "better ways to write programs", constantly re-exploring visual programming (Scratch and its spinoffs), it's interesting to me that the ALGOL-children (C and the like) have completely lost this way of developing programs. What is there to learn, both from the technology itself and from how we forget?
Parinfer looks very clever, but I'm not afraid of "hotkeys" (I use emacs) and I don't want to do manual indentation. Is there any benefit over paredit for me?
EDIT: I don't mean that to sound critical of parinfer development. Developing the software on top of a formal relationship between indentation and parens sounds like a very interesting and laudable approach.
What I'd love to see is work on producing relaxed modes inheriting from paredit for use in non-lisps such as python.I use a very slightly modified paredit for python and have done every day for years. It gets it 95% right.
This comment misses the point entirely. The point isn't to mitigate having to type them, it's to help keep structural preservation. All of these structural editors also do so much more than just close the parens. They allow you to edit the code as the tree it is as well as navigate it as such. Without the parens actually being there, you couldn't do that in a determininistic way, thus the auto-closing of parens is more of a side effect than anything else.
(+ 1 2 (x 3 4))
+
1
2
x
3
4
+ 1 2
x 3 4If there were multiple markers stacked up in a C based language they'd be visually distinguished from one another ];} and you'd at least have a chance.
Look, we can get used to anything so clearly the lisp way can work. But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of. Simplicity in syntax is great but lisp really overdid it. If you invented a human language that could get by with only 12 letters, I wouldn't give you kudos for that because of the general principle that simplicity is good...
When you autoindent, the indentation of the code makes its underlying structure (AST) clear without having to count either parentheses in Lisp or braces in C. By the 1970s, autoindenting editors (EMACS) and structure editors had been developed for Lisp. In the C/Unix world, until recently, indentation and parenthesis/brace counting had to be done by hand. Among C programmers (but not, to their credit, Java programmers) there are still arguments about code layout, a problem solved decades ago for Lisp.
Nope! The vi editor has a :set lisp mode, and a % command to jump to matching parens. I think that was already in vi in the 1980's.
FWIW, % is described in POSIX; Lisp mode isn't.
What I was trying to say is that these things are easier to do by hand in C than in Lisp, but more difficult to do algorithmically, and this discouraged people developing syntax-aware editors, and encouraged the plethora of competing C styles.
In the Lisp world, the difficulty of doing these by hand resulted in earlier syntax aware editors and the consensus on style.
int main(void)
{ FILE *f = fopen("commands", "r");
if (f)
{ char line[512];
while (fgets(line, sizeof line, f))
{ ... }
fclose(f);
return 0; }
else
{ printf("failed to open file\n");
exit(EXIT_FAILURE); } }Java programmers have sensibly agreed on a single style, despite there being as many choices for Java as there are for C.
... but you also will find that most of your code is highly readable!
Lisp code (or at least Common Lisp code) can be highly readable. I never need to count parenthesis to understand code. The indentation itself makes the structure obvious. And if there is any doubt, the editor (say, Emacs) will tell me where each expression ends.
> "But it seems pretty straightforward to me why people think it's visually confusing and why lisp gets made fun of."
"Appearances" are not the same as "reality".
I went to Rosetta Code and grabbed the implementations of Conway's Game of Life in Racket, Ruby, Python, and Java. For each one, I manually removed comments and string literals. Then I wrote a little script. It looks at each character in the file and groups them into categories:
bracket: ()[]{}
whitespace: space\t\r\n
text: a-zA-Z01-9_
punctuation: =,;<>-'!|?:#/*%+.
bracket punctuation
life.java 13.25% 27.52%
life.py 13.27% 21.95%
life.rb 9.56% 23.73%
life.scm 22.29% 28.30%
Most languages have multiple levels of precedence. The entire point of that is to allow eliding explicit bracketing characters for commonly nested subexpressions. You may dislike that feature, which is reasonable. But I don't think you can argue that it doesn't exist and doesn't accomplish what it intends to do. Consider:
var isCloser = x1 * x1 + y1 * y1 < x2 * x2 + y2 * y2 // 0 brackets
(define is-closer (< (+ (* x1 x1) (* y1 y1)) (+ (* x2 x2) (* y2 y2)))) ; 16 bracketsSo in fact "Other languages have more punctuation characters than Lisp." is not an objective statement at all, since it relies on the definition of punctuation, which is subjective or at least language-specific.
bracket punctuation
life.java 13.25% 27.52%
life.py 13.27% 21.95%
life.rb 9.56% 23.29%
life.scm 22.29% 24.81%
I suspect that yorwba has a good point re. identifiers (note too that *, + and - are allowed & quite common in Lisp).
Also note that Racket is not Scheme, so using '.scm' as an identifier for it is a bit misleading:-)
But generally, Lisps aren't intended to be compact in the small, but semantically regular, which can be a definition of "simpler", and give smaller code in larger systems. Source code compression for syntactically-atomic operations is where all the other varied punctuation comes from, which addresses snippets of code, not large abstraction gains. So yes, there are cases where Lisps will have more parens than other languages have total punctuation. Even in such cases, the other languages are more complex to read, both for humans and for machines.
Note that I didn't only mention quantity, but also more complex interspersal. Most other languages have commas for field separators, while Lisps tend only to use naturally-occurring whitespace. For instance, f(a,b,); is commonly an error, while (f a b ) is valid Lisp syntax, as a low baseline example. Prolog-derived languages go even more nuts with ; and . than C-style terminators. And the brackets vs braces vs parens all nest together. The }]);}]); style closing mess is very common in JavaScript, where objects and function objects nest heavily due to its callback-centric style.
Other languages also have a mix of infix, postfix, and prefix ordering:
fun5((fun1() op3 fun2()).fun4()).fun6();
And the biggest reason why things are so much more regular in Lisp is metaprogramming, code generation, and code transformation. This is such a pain in the butt in other language's direct source code representations, unless separate ASTs are involved, and ASTs aren't editable as plain source code for template-style use. Separate libraries could tackle this, but they would have to be maintained in lockstep with the language itself, and manually replicate every subtle nuance of the language to avoid bugs (including replicating reference implementation bugs).
So this whole thing is about technical complexity of representation, not just personal preference.
And for a bit of levity: http://www.loper-os.org/wp-content/parphobia.png :)
What do you mean by this? In Prolog, (;)/2 is simply a binary infix operator, so that you can write a term of the form:
;(A, B)
( A ; B )
In Prolog, you can always use the predicate write_canonical/1 to obtain the canonical representation of any term, which is completely regular. In the case above, we get:
?- write_canonical( (a ; b) ).
;(a,b)
We have also several other ways to inspect the term, such as functor/3:
?- functor((a;b), Functor, Arity).
Functor = (;),
Arity = 2.
Further, the period '.' has a dual role as the primary functor for non-empty lists, and also to mark the end of a term.
For example, in a Prolog fact of the form:
hello(world).
hello(world) + universe.
?- write_canonical(hello(world) + universe).
+(hello(world),universe)
If you want, you can always use the canonical representation of Prolog terms in your code. However, this would make writing and reading Prolog at least as inconvenient as Lisp, because you then have to write everything in prefix notation instead of being able to benefit from infix operators too.
For example, using prefix syntax, you would define a Prolog rule as:
:-(Head, Body).
Head :- Body.
#=(X,+(5,3))
X #= 5+3
In talking against separators, in "Prolog-derived" languages like Erlang (and other custom derivations I've dealt with), separators are used even between clauses. Most other languages use separators just for fields, and use straight terminators for statements. Prolog itself gets a pass because these separators are literally ANDs and ORs which flow as logical expressions through the backtracking search.
Even toplevel expressions defining different match parameters for the same head require differentiating separators from a final terminator for that head in Erlang, whereas Prolog just deals with independently terminated head matches just fine. The Erlang code is much more removed from a logical AND/OR flow into more standard programming models, yet is still separator-based. Instead of thinking of the logical, partial evaluation possibilities of
x AND y AND z
statement 1,
statement 2,
statement 3.
Why is it so unimaginable that people can just live with all those parentheses? The only parenthesis-related fragment in my .emacs is the following:
(keyboard-translate ?\( ?\[)
(keyboard-translate ?\[ ?\()
(keyboard-translate ?\) ?\])
(keyboard-translate ?\] ?\))
puts("Hello")
(puts "Hello")
if (i < x) {
puts ("low");
} else {
puts ("high");
}
(if (< i x)
(puts "low")
(puts "high")
)
Prefix notation is hard, at least for people whose native language is S-V-O, and not V-S-O.
So
i < x
< i x
"if" is interesting, because it seems to do fine in prefix notation, and puts() is also a bit weird because its subject is missing/implied:
stdout puts:"hello".
(< a b c) := a,b,c are ordered from smaller to larger
And this allows for multiple comparisons, which is useful.
Edit: < could be called increasingp
Example:
(remove-if (op < 3) list)
But the syntax invites a misreading as "less than three".
> Edit: < could be called increasingp
How about: crescendo!
I don't like using it in this case because that amounts to admitting there is some kind of problem. I'd rather fix the cognitive root cause in the brain.
IIRC racket allows you to write (x . < . 5), and some schemes have curly infix (a srfi) where {x < 5} gets translated to (< x 5).
(People do complain about prefix vs infix, but its very much drowned out by the people who complain about parentheses)
Infix notation only works "naturally" for two operands.
Or n operands where the operator is the same (think a + b + c + ... ).
The Readable Lisp project for Lisp without parentheses allows using infix notation in Lisp for these two use cases.
a raisedTo: 2
a ** 2 (< 1 (+ 2 3))
(< 1 5)
true
(let [a 1
b 2
c 3])
(assoc dict :key1 val1
:k2 5
:k3 "value"))
In
(let [a 1
b 2
c 3])
let a = 1,
b = 2,
c = 3
let a = 1, b = 2, c = 3
let a = 1
let b = 2
let c = 3
(let [a 1, b 2, c 3])
(let a 1, b 2, c 3)
Really? Lisp is the most concise and clear language I've ever used. There is almost zero boilerplate when writing it.
The example was a simple one to get the idea across, you can create your own functions and do the same too:
(my-let [a 1
b 2
c 3])
(-> a b c d e f)
(f(e(d(c(b(a))))))
[1] https://github.com/oakes/play-clj-examples/blob/master/break...
You mean at the expense of losing the meaningful structure?
I.e. the token count is one token smaller between these examples, in favor of the Lisp:
(let [a 1
b 2
c 3]) ;; 11 tokens
let a = 1,
b = 2,
c = 3 // 12 tokens
We have no idea if/when the variables in the second version go out of scope.
This is a huge problem in languages that aren't lisp.
If it weren't it would just be a def/setf/defvar/defparameter.
In the example given, assuming let has the same properties, we have no idea when the second 'let' statement ends, you would need something to signify the end of the block... there isn't anything in the given example. It could be implicit whitespace or something, but that isn't clear.
If it were truly algol it would probably have an 'endlet' symbol at the end of the let, for example. If it were C it would require curly brackets, python out-dentation, ocaml something else(!?).
Anyway, I suspect you're a troll,
good day.
The crystal clear point of ohyes's observation is that the token count is unequal, in a sense: the Lisp expression is defining variables and delimiting the scope, and includes tokens which establish scoping, whereas the Algol-like snippet is only defining variables, letting an unspecified surrounding program delimit their scope. That program is going to require some syntax in order to delimit that scope; that syntax is not shown and so its tokens are not counted.
I get that you think having to wrap your entire program in an extra set of delimiters is super special, but it's really fucking not.
print(sin(pow(2, x)))pow() is a good example, as it was used a lot as an example for operator overloading in, for example, Swift. So instead of
pow(2,x)
2 ** x
If you extend infix syntax to named methods, the problem goes away:
2 raisedTo:x
So in a sense I agree with you that the difference is not huge for some expressions, but for me that doesn't solve the mystery, but only shifts it.
Also, infix has the unfortunate problem of requiring operator priorities to parse.
f(2, g(3, 4))
2 f 3 g 4
(2 f (3 g 4))
which is arguably how most sane engineers would write it.
> which is arguably how most sane engineers would write it
I'm always wary of this sort of statement.
That is, the complaints you are naming go all the way to how "non-programmers" can't read most programs. They are much more rigid in structure than normal sentences, and to pretend that C or other syntax is somehow more natural misses that they all take training.
This is also why some languages had a specific "then" in their syntax. Most have dropped that, since it could often be completely inferred. (And many languages have an "unless" or similar construct.)
All of that is to say my point is that you are only used to the other way. It is not more natural in most any sense of the word.
Parentheses are also visually designed. We could make a languagein which ) opens a list, and ( closes it. The machiine wouldn't care, but the code would look like this:
)defun add )a b(
)+ a b((
Here is a mental trick that might help with < and > in Lisp reading. Forget the relationship to the math symbols, and think of it as music symbols:
< is crescendo (play gradually louder):
> is decrescendo.
It's very useful, for two arguments it works just like x < y, and it makes you think about (< x y) as "in rising order: x and y"
Note that in the imperative mood, English is normally VO, with an implied second person subject.
That's pretty much exactly what prefix notation is.
In “add six and two”, “add” is the verb, “six and two” is a composite direct object, and the subject (“you, the reader/listener” is implied.) This maps quite nicely to (add 6 2).
Infix mathematical and logical notation is a tiny part of the code that I write. More complicated mathematical productions lead me to fully parenthesize the statement anyway.
Further, to my knowledge there isn't a high level 'fully infix' language. I suspect it would be pretty difficult to use.
the parenthesis argument is literally:
verb(nouns) + some syntactic sugar
vs.
(verb nouns) + some different syntactic sugar that's often user defined.
This is an excellent argument for buying my children HP reverse polish scientific graphing calculators. I think I had a 48 series. Get your kids into the church early.
I also think that comparing programming language grammar to natural language grammar isn't helpful at all. Fluency is moving beyond the point of having to translate everything to your native language in your head on the fly.
I have never found or read about any lisper (any programmer who wrote useful, complete code in Lisp) complaining about parenthesis or syntax. They all either love it or at least don't complain about it.
(if (< i x)
(progn
(puts "low")
(puts "high")))I have also used Atom with Parinfer to teach a nontechnical designer the basics of clojure. Enough to build templates using hiccup for her resume, and personal website. I don't think smartparens or paredit would be anywhere near as easy for her to pick up.
If you're used to indentation being meaningful as some langs do, you should probably try out clojure/script with parinfer.
edit: I see, the point of parinfer is to not use commands or hot keys. I'm going to play with your site and if the slurp/barf behavior is any better than paredit.
But probably worth spending some time with ITS, TOPS-10, and TOPS-20 & digging around with TECO and its descendants which came to be emacs, and probably checking into 4.2/4.3BSD as well..
The former group is pretty much the platform for early LISP (when lisp was still in caps :b ), and the latter, well, alot of good stuff happened here.. plus built in franz lisp and the lisp mode for (real) vi ..