As one of the earlier commenters pointed out, lisp welcomes you to the 1960s.
SCNR
User issue here. I never have the problem you refer to. Don't have the editor/IDE insert the parens/brackets. Have it check them for you. Emacs can do a momentary highlight of the opening paren/bracket whenever you type the close of the pair. I used to use that to make sure I'm writing exactly what I thought I was writing. If my code is too convoluted for me to know that I'm correct in a split second when seeing the open paren highlight, then I know it's time for me to refactor/rewrite the method.
In my present project, I use a similar facility in the Smalltalk browser.
NO. Sorry but you're doing it wrong. Relying on the editor to highlight parentheses is a highly inefficient and error-prone way to work. It's distracting, it wastes mental cycles and inhibits flow.
The correct way is to configure emacs so that when you press a certain key (in my case, right shift because I configured my keyboard so I can activate left shift with my thumb), emacs inserts "()" and puts the cursor in the parentheses. No need to remember or count closing parentheses this way.
It's been a really long while since I last counted parentheses for ANYTHING. Like, let's say I write a let with one variable, and the value is a really deeply nested expression and now I'm done with it and I want to write the body of the let. What do I do? I DON'T COUNT PARENTHESES. I go back to the opening parenthese for the variable declarations of the let, then I skip over that form (the variable declarations) with C-M-f (forward-sexp), right to the body of the let. Then I use C-j (newline-and-indent) and then I can write the body of the let. (if the value form is really long I might skip a few parentheses and use C-M-b to get back at or near the opening parenthese of the variable declarations).
So, executive summary, you walk the structure but you NEVER count parentheses. Like, once every four months I might screw up and delete a parenthese and then the editor and me are both pretty confused, but it's such a total non-issue. And even then, I don't count parentheses a lot because I try to walk the structure by skipping over forms and see what works and what doesn't, and I might tell emacs to reindent some of the code and I immediately see what's wrong. With a proper structure editor, unbalancing the parentheses couldn't even happen.
The correct way is to configure emacs so that when you press a certain key (in my case, right shift because I configured my keyboard so I can activate left shift with my thumb), emacs inserts "()" and puts the cursor in the parentheses. No need to remember or count closing parentheses this way.
No, sorry you are doing it "wrong!" :) I also use the insert () technique. I basically use whichever technique is optimal in context. Please note that your assertions about flow and distractions are highly subjective.
http://www.cyberbore.com/puzzle/klok.html
Incidentally, I no longer use emacs, and I don't write Lisp.
Incidentally, I use emacs and Lisp every day.
Here we are in 2010 and most programming languages still contain tons of semicolons, parans, and curly braces, and the only reasons I can find for this is:
* Language y looks like langage x because everyone's comfortable with language x's syntax already
which is contradicted by * Having trouble with curlybraces and semicolons? Your IDE will do that for you.
We need IDEs to deal with ugly syntax, and we have ugly syntax cos we've always had ugly syntax, but we then use IDEs to write the ugly syntax.
And then I hear people deride VB, Ruby, and Python for it's lack of curly braces and parens.
So, I don't think IDEs are the answer. I think better syntaxes are the answer. For example, I used Textmate's easy HTML completion shortcuts for a long time. Then I found HAML, and I didn't need to close tags anymore. I use Sass, and now my CSS doesn't need ; or {} anymore. Same with CoffeeScript.
C#, Java, Lisp, Perl, JavaScript are all great powerful languages, but I just get really uncomfortable hearing people defend the syntax with "just use your IDE". We're programmers. How come we're not interested in saying "hey, let's fix these things!" If the argument is "IDEs make you more productive in language X" then doesn't that say something about language x?
Just some thoughts.
Python is almost there in terms of language simplicity, but I'd much rather count parens than count spaces/tabs. The former are visible. The latter are only visible through secondary effect.
Any tool can be abused. Not using automation for truly mindless tasks like counting parens is often just a knee-jerk reaction that precludes real thinking about the cost/risk/benefit of the tool.
Programming has always been full of idiots who turn off their brains. Maybe modern tools make this a bit too easy. I'd posit that one way to detect programmers with such proclivities is to discuss tools with them, and see if they give you back unsupported prejudice or reasoned analysis. (Really be wary of the ones who try to pawn off prejudice as reasoned analysis!)
There seems to be something inherent in us that feels the need to turn our tools into our religion. It's not terribly productive.
SCNR is an old usenet acronym and stands for "sorry. could not resist". I was a) being sarcastic and b) just making fun for the list crowd. I totally agree that if the parens issue is a non-issue for you and you feel comfortable and productive writing lisp code than go ahead.
In fact, I have the utmost respect for people able to wrap their heads around that syntax.
For the true rockstar coder "wrapping your head around" any reasonable syntax should be a triviality.
Never had the dubious pleasure of trying to decipher another person's APL code, eh?
Then again, you did say "reasonable"...
Wrapping your head around APL wins my respect. Lisp? You get a pat on the head for that, maybe.
{ 'foo':'barbaz'
, 'k2':'v2'
}
CL's reader is especially rich, and it's programmable....
No on both counts.
(1) S-expressions aren't literals.
(2) s-expressions are not "parsed" by calling lisp eval. Lisp eval's argument is an s-expression - it doesn't parse anything. (It also doesn't read anything.) Lisp read turns character sequences into s-expressions.
> But JSON wins over s-expressions too, because s-expressions are too simple. How do you represent John Smith as an s-expression?
If you'd like, exactly the same way you'd represent it in JSON, because lisp's read handles a superset of the JSON datatypes.
> software that consumes s-expressions has to know how to interpret their structure
As does JSON.
Take your example John Smith. What JSON datatype do you expect to get? (JSON just has numbers, strings, arrays, booleans, and hashes, where the keys have a restricted format.)
But, there was something Lisp did right that no other mainstream scripting language has - it separated the reader and the evaluator. You can eval Perl or Ruby or Python, but not securely read it. This goes for Javascript too - you can eval a JSON, but you'd be an idiot.
Huh? CL's reader handles structs, hashes, and vectors in addition to strings, lists, atoms (with packages), lots of number formats (including Roman), and the ability to express AGs, not just trees (yes, cyclic too). Plus some other things that I forget. (Arrays?)
What else do you want to read?
No matter - CL's reader is programmable....
It's probably bad you can express cyclic graphs. That means you'll have to watch for denial-of-service attacks phrased as cyclic data.
Programmable reader isn't the point. That gets you back into defining your own syntax. The point is to have a standard.
You can turn it off. However, if cyclic graphs (or general DAGs) are important, supporting them means that you don't have to roll your own.
> Programmable reader isn't the point. That gets you back into defining your own syntax. The point is to have a standard.
The writer and reader have to agree no matter what you do. A programmable reader means that you don't have to roll your own in more cases. And, it makes it easier to test the third-party writers. (The reader folks can just publish the read-table.)