5 ms·
... while the lispers where still counting the closing parens needed to finally get their code running SCNR
by pilif 17y ago
... while the lispers where still counting the closing parens needed to finally get their code running
SCNR
- stcredzero 17y agoOnly the ones too clueless to use Emacs or another editor that does it for you.
- nuclear_eclipse 17y agoFor some reason, every time I let an editor automatically insert a closing parenthesis, quotation, or brace, I almost always end up with extras at the end, which is just as frustrating, if not harder to debug, as not enough. Maybe it's the way I tend to backstep as I think my way through the code flow, but it never ceases to happen whenever I step foot into Eclipse or Visual Studio...
- stcredzero 17y agoFor some reason, every time I let an editor automatically insert a closing parenthesis, quotation, or brace, I almost always end up with extras at the end 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.
- Hexstream 17y ago"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." 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.
- stcredzero 17y agoNO. 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. 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 http://www.cyberbore.com/puzzle/klok.html Incidentally, I no longer use emacs, and I don't write Lisp.
- Hexstream 17y agoIf there's backing to the assertion that I'm doing it wrong in there, I didn't find it. Incidentally, I use emacs and Lisp every day.
- stcredzero 17y agoYes, so your coding context is very different from mine. I don't think you can make a very cogent claim of "wrongness."
- bphogan 17y agoMaybe it goes back to my frustrations with Dreamweaver, but I always felt like an IDE only served two purposes - to prevent developers from really learning a language (autocompletes, intellisense, etc) and making up for poorly designed, overly-verbose syntaxes. 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.
- stcredzero 17y agoWell, that's quite an extrapolation from my recommendation to use automation to match brackets/parens. 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!)
- drunkpotato 17y agoThis thread has been yet another fruitful contribution to the language wars. There seems to be something inherent in us that feels the need to turn our tools into our religion. It's not terribly productive.
- deleted 17y ago[deleted]
- pilif 17y agono. but fun. 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.
- stcredzero 17y agoIf you really think "wrapping your head around" the almost non-existent syntax of Lisp is a reason to respect someone, then I suggest you might delve a little further in your CS/programming studies and find many more wonderful and interesting things. For the true rockstar coder "wrapping your head around" any reasonable syntax should be a triviality.
- ewjordan 17y agoFor 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"...
- stcredzero 17y agoYou don't have to tell me about APL syntax. For our senior year CS project, we implemented APL with unlimited precision arithmetic. Wrapping your head around APL wins my respect. Lisp? You get a pat on the head for that, maybe.