5 ms·

As one of the earlier commenters pointed out, lisp welcomes you to the 1960s.

by anamax 17y ago

patio11 17y ago
Sorry we were late to the party, guys, we just got so wrapped up in writing software that people actually use.
- pilif 17y ago
  ... while the lispers where still counting the closing parens needed to finally get their code running SCNR
  - stcredzero 17y ago
    Only the ones too clueless to use Emacs or another editor that does it for you.
    - nuclear_eclipse 17y ago
      For 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 ago
        For 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 ago
        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. 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.
    - bphogan 17y ago
      Maybe 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 ago
        Well, 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 ago
    This 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 ago
      no. 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 ago
        If 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 ago
        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"...
        stcredzero 17y ago
        You 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.
- jrockway 17y ago
  The Lisp programmers were writing airline reservation systems... the other programmers were writing board-game generators.
  - tlack 17y ago
    Ah, that one example of a successful Lisp project.
- cema 17y ago
  You are using some lisp software right now.
- peterbessman 17y ago
  Put differently: if the goal is making money, lisp is frequently not the best choice.
cwp 17y ago
Yeah, sure. S-expresssions are literals in Lisp, and can be "parsed" calling eval. But I think that misses the larger point made by the OP. JSON is really useful even in languages other than Javascript. JSON wins over XML because XML is too complex and thus ambiguous. But JSON wins over s-expressions too, because s-expressions are too simple. How do you represent John Smith as an s-expression? Sure, it can be done. But as with XML, software that consumes s-expressions has to know how to interpret their structure, even if it doesn't have to parse the surface syntax.
- weichi 17y ago
  It's true that s-expressions don't give you a literal syntax for hashmaps or arrays, but note that some lisps (e.g. Clojure) do support these natively … and in a syntax that's better than JSON since you don't have to type all those annoying commas ;-)
  - sophacles 17y ago
    You know I never quite got that comma thing. For instance in python, the only reason it is necessary is because {"foo": "bar" "baz", 'k2':'v2'} is the same as {'foo':'barbaz', 'k2':'v2'}. Getting rid of auto-concatination allows for {'foo':'barbaz' 'k2':'v2'} which is pretty easy to parse base on tokens and ':'. It also eliminates a pretty common bug, in which there is kv pair per line, and the line ends with ',', except for the last line which does not have the ','. (The following line has a '}'). The common bug being adding a new kv pair and missing the ','.
    - blasdel 17y ago
      Python lets you put the commas before the items, like so: { 'foo':'barbaz' , 'k2':'v2' } Ruby doesn't like that though. Both Python and Ruby will ignore an extra trailing comma on the last item, which gives you another way of avoiding the common bug you describe.
      - weichi 17y ago
JulianMorrison 17y ago
Not enough data types in CL or Scheme's reader (Clojure wins here) and no standard between the lisps. 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.
- anamax 17y ago
  > Not enough data types in CL [reader] 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....
  - JulianMorrison 17y ago
    You can do hashes in the CL reader? How? I don't recall being able to, from back when I was trying out CL. 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.
    - anamax 17y ago
      > > 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. 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.)

As one of the earlier commenters pointed out, lisp welcomes you to the 1960s.

by anamax 17y ago

As one of the earlier commenters pointed out, lisp welcomes you to the 1960s.

patio11 17y ago

Sorry we were late to the party, guys, we just got so wrapped up in writing software that people actually use.

pilif 17y ago
... while the lispers where still counting the closing parens needed to finally get their code running SCNR
- stcredzero 17y ago
  Only the ones too clueless to use Emacs or another editor that does it for you.
  - nuclear_eclipse 17y ago
    For 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 ago
      For 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 ago
        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. 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.
  - bphogan 17y ago
    Maybe 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 ago
      Well, 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 ago
  This 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 ago
    no. 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 ago
      If 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 ago
        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"...
        stcredzero 17y ago
        You 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.
jrockway 17y ago
The Lisp programmers were writing airline reservation systems... the other programmers were writing board-game generators.
- tlack 17y ago
  Ah, that one example of a successful Lisp project.
cema 17y ago
You are using some lisp software right now.
peterbessman 17y ago
Put differently: if the goal is making money, lisp is frequently not the best choice.

cwp 17y ago

Yeah, sure. S-expresssions are literals in Lisp, and can be "parsed" calling eval. But I think that misses the larger point made by the OP. JSON is really useful even in languages other than Javascript. JSON wins over XML because XML is too complex and thus ambiguous. But JSON wins over s-expressions too, because s-expressions are too simple. How do you represent John Smith as an s-expression? Sure, it can be done. But as with XML, software that consumes s-expressions has to know how to interpret their structure, even if it doesn't have to parse the surface syntax.

weichi 17y ago
It's true that s-expressions don't give you a literal syntax for hashmaps or arrays, but note that some lisps (e.g. Clojure) do support these natively … and in a syntax that's better than JSON since you don't have to type all those annoying commas ;-)
- sophacles 17y ago
  You know I never quite got that comma thing. For instance in python, the only reason it is necessary is because {"foo": "bar" "baz", 'k2':'v2'} is the same as {'foo':'barbaz', 'k2':'v2'}. Getting rid of auto-concatination allows for {'foo':'barbaz' 'k2':'v2'} which is pretty easy to parse base on tokens and ':'. It also eliminates a pretty common bug, in which there is kv pair per line, and the line ends with ',', except for the last line which does not have the ','. (The following line has a '}'). The common bug being adding a new kv pair and missing the ','.
  - blasdel 17y ago
    Python lets you put the commas before the items, like so: { 'foo':'barbaz' , 'k2':'v2' } Ruby doesn't like that though. Both Python and Ruby will ignore an extra trailing comma on the last item, which gives you another way of avoiding the common bug you describe.
    - weichi 17y ago

JulianMorrison 17y ago

Not enough data types in CL or Scheme's reader (Clojure wins here) and no standard between the lisps. 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.

anamax 17y ago
> Not enough data types in CL [reader] 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....
- JulianMorrison 17y ago
  You can do hashes in the CL reader? How? I don't recall being able to, from back when I was trying out CL. 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.
  - anamax 17y ago
    > > 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. 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.)