4 ms·

Its ok to disagree friend, but when 95% percent of your bugs are syntax related rather than algorithmic design... it fails the sanity check. Have a gloriously

Its ok to disagree friend, but when 95% percent of your bugs are syntax related rather than algorithmic design... it fails the sanity check. Have a gloriously wonderful day =)

wiseowise 4y ago
> but when 95% percent of your bugs are syntax related rather than algorithmic design... it fails the sanity check. And you, of course, have study that proves it, right?
- Joel_Mckay 4y ago
  Anecdotes are funny this way, as the data is 100% accurate or 100% arbitrary. Enhance your calm. =)
  - wiseowise 4y ago
    QED
    - Joel_Mckay 4y ago
      Just google "lisp syntax error" for the hit count if you are feeling petulant. =)
      - Jach 4y ago
        "About 1,810,000 results (0.48 seconds)" Googling "python syntax error" "About 172,000,000 results (0.46 seconds)" ???
        drekipus 4y ago
        Don't get him started on python readability issues!!
        Joel_Mckay 4y ago
        Python is well organized, but has a fundamentally broken threading model. Again, depends on the intended use-case. =)
        Joel_Mckay 4y ago
        You need to correct for the popular share of the languages. Python is 48.07% Lisp doesn't even show up in lists ;)
        kazinator 4y ago
        If the 172,000,000 figure from Google were not a brazen lie, it would indicate that for every developer on the planet using any stack, there exist several web pages mentioning Python syntax errors.
        Joel_Mckay 4y ago
        After a few years of seeing code build abominations, I am biased to believe that number may be plausible. Especially with automated testing frameworks dumping logs onto public areas of the web for the spiders to crawl. I like data, but the hate in this place is unbelievable. Have a great day, and happy computing my friend. =)
reikonomusha 4y ago
Lispers have been using structural editing since at least the 80s. Structural editing essentially allows modification to Lisp programs to be made as edits to a data structure with tokens. It sounds radical but it's really quite simple, at least in a language like Lisp, where (setf x 5) is a piece of code that is truly and immediately represented by a data structure (a list containing the symbol SETF, the symbol X, and the number 5). Let's do a routine example. In your editor, how would you get from (f x (y|)) z to (f x y| z) if the '|' was your cursor? Maybe you think you should click around and delete the right parentheses, and carefully balance them. With structural editing, a Lisp programmer might first do a "splice": (f x (y|)) z ;; splice: press Alt+s (f x y|) z and then they will do a "slurp" (slang for moving the next thing after the cursor into the current enclosing parentheses): (f x y|) z ;; slurp: press Control-<right> (f x y| z) We've managed to get to our destination by using only two structural commands that makes a parenthesis-mismatch error fundamentally impossible. These are examples written with a package called "Paredit" in mind, and it actually makes editing Lisp a distinct joy compared to character-based editing of other languages. Some Lisp programmers prefer slightly different styles of structural editing, but they all reduce to the same motivations: Edit a Lisp program's structure, not its characters. So, contrary to popular belief, Lisp programmers do not count parentheses. Lisp programmers' eyes do not glaze over at the sight of Lisp. Syntax errors are probably a <1% occurrence out of all of the errors one encounters. Though purely informally empirical, I'd be willing to get that syntax errors are far less common in Lisp compared to syntax-rich languages like C++, Haskell, etc. People who dabble with Lisp for 15 minutes in notepad.exe invariably run into syntax errors, but that is not a reflection of what serious hobbyists and professional Lisp programmers do.
- Joel_Mckay 4y ago
  While I appreciate a parenthesis laden straw man argument, this just reinforces the assertion about poor readability. Have a great day =)
  - reikonomusha 4y ago
    Sorry, I made a mistake. You said Lisp has a readability issue which I interpreted a statement of generality, but I think you meant Lisp is difficult for me to read which I have no business arguing against, except to offer you guidance on what I believe are best practices for reading and writing Lisp. (In short, it's to use an editor specifically equipped to write Lisp. It gives you canonical indentation and structural editing. Emacs is the most popular choice, but there are extensions to Vim and VSCode; as well as full-blown commercial IDEs (plural!) by LispWorks and Franz Inc.)
aidenn0 4y ago
Are you saying that Lisp has a readability issue just because you have trouble reading it? 1. I spend more time programming C than Lisp, but am more prone to syntax errors in C than lisp, so my experience is quite different than yours 2. Syntax bugs have little to do with readability; that has more to do with writeability. 3. Most languages make it possible to write code that is inscrutable, but that is not necessarily an indictment of their readability.
- Joel_Mckay 4y ago
  1. How quickly can you understand what others have written in a large lisp project. I found I was spending a lot of time interpreting what was going on rather than the design implementation process itself. 2. unless some clown thought conditional tail recursion was super awesome for the next guy. 3. All code is terrible, but some of it is useful... and if it is only useful to a few than it fails as a language. Keep in mind I learned on an RPN machine, so understand the sirens song lisp sings. ;)
  - aidenn0 4y ago
    RE: 2 Tail recursion is non-idiomatic in Common Lisp; both because the standard does not guarantee tail-call elimination (as opposed to, say, Scheme) and because dynamic-binding, which is idiomatic in Common Lisp reduces the number of calls that are in a tail position. Also, tail-recursion is entirely divorced from syntax; perhaps you meant semantics? For example GCC will optimize tail calls in a rather broad number of contexts.
    - Joel_Mckay 4y ago
      If I recall correctly, some Lisp dialects had a super character that world close n open parentheses left open. You may have confused interesting with useful... Have a nice say ;)
  - ortsan 4y ago
    1. In an average project Lisp would rank fairly high for me. In fact for making meaningful changes in an average quality large code base I'd rank it at the top, my order being (best first): Lisp, C, Java, C++, Python It all depends, e.g., C++ would rank higher in a very high quality code base.

Its ok to disagree friend, but when 95% percent of your bugs are syntax related rather than algorithmic design... it fails the sanity check. Have a gloriously wonderful day =)

wiseowise 4y ago

> but when 95% percent of your bugs are syntax related rather than algorithmic design... it fails the sanity check. And you, of course, have study that proves it, right?

Joel_Mckay 4y ago
Anecdotes are funny this way, as the data is 100% accurate or 100% arbitrary. Enhance your calm. =)
- wiseowise 4y ago
  QED
  - Joel_Mckay 4y ago
    Just google "lisp syntax error" for the hit count if you are feeling petulant. =)
    - Jach 4y ago
      "About 1,810,000 results (0.48 seconds)" Googling "python syntax error" "About 172,000,000 results (0.46 seconds)" ???
      - drekipus 4y ago
        Don't get him started on python readability issues!!
        Joel_Mckay 4y ago
        Python is well organized, but has a fundamentally broken threading model. Again, depends on the intended use-case. =)
      - Joel_Mckay 4y ago
        You need to correct for the popular share of the languages. Python is 48.07% Lisp doesn't even show up in lists ;)
        kazinator 4y ago
        If the 172,000,000 figure from Google were not a brazen lie, it would indicate that for every developer on the planet using any stack, there exist several web pages mentioning Python syntax errors.
        Joel_Mckay 4y ago
        After a few years of seeing code build abominations, I am biased to believe that number may be plausible. Especially with automated testing frameworks dumping logs onto public areas of the web for the spiders to crawl. I like data, but the hate in this place is unbelievable. Have a great day, and happy computing my friend. =)

reikonomusha 4y ago

Lispers have been using structural editing since at least the 80s. Structural editing essentially allows modification to Lisp programs to be made as edits to a data structure with tokens. It sounds radical but it's really quite simple, at least in a language like Lisp, where (setf x 5) is a piece of code that is truly and immediately represented by a data structure (a list containing the symbol SETF, the symbol X, and the number 5). Let's do a routine example. In your editor, how would you get from (f x (y|)) z to (f x y| z) if the '|' was your cursor? Maybe you think you should click around and delete the right parentheses, and carefully balance them. With structural editing, a Lisp programmer might first do a "splice": (f x (y|)) z ;; splice: press Alt+s (f x y|) z and then they will do a "slurp" (slang for moving the next thing after the cursor into the current enclosing parentheses): (f x y|) z ;; slurp: press Control-<right> (f x y| z) We've managed to get to our destination by using only two structural commands that makes a parenthesis-mismatch error fundamentally impossible. These are examples written with a package called "Paredit" in mind, and it actually makes editing Lisp a distinct joy compared to character-based editing of other languages. Some Lisp programmers prefer slightly different styles of structural editing, but they all reduce to the same motivations: Edit a Lisp program's structure, not its characters. So, contrary to popular belief, Lisp programmers do not count parentheses. Lisp programmers' eyes do not glaze over at the sight of Lisp. Syntax errors are probably a <1% occurrence out of all of the errors one encounters. Though purely informally empirical, I'd be willing to get that syntax errors are far less common in Lisp compared to syntax-rich languages like C++, Haskell, etc. People who dabble with Lisp for 15 minutes in notepad.exe invariably run into syntax errors, but that is not a reflection of what serious hobbyists and professional Lisp programmers do.

Joel_Mckay 4y ago
While I appreciate a parenthesis laden straw man argument, this just reinforces the assertion about poor readability. Have a great day =)
- reikonomusha 4y ago
  Sorry, I made a mistake. You said Lisp has a readability issue which I interpreted a statement of generality, but I think you meant Lisp is difficult for me to read which I have no business arguing against, except to offer you guidance on what I believe are best practices for reading and writing Lisp. (In short, it's to use an editor specifically equipped to write Lisp. It gives you canonical indentation and structural editing. Emacs is the most popular choice, but there are extensions to Vim and VSCode; as well as full-blown commercial IDEs (plural!) by LispWorks and Franz Inc.)

aidenn0 4y ago

Are you saying that Lisp has a readability issue just because you have trouble reading it? 1. I spend more time programming C than Lisp, but am more prone to syntax errors in C than lisp, so my experience is quite different than yours 2. Syntax bugs have little to do with readability; that has more to do with writeability. 3. Most languages make it possible to write code that is inscrutable, but that is not necessarily an indictment of their readability.

Joel_Mckay 4y ago
1. How quickly can you understand what others have written in a large lisp project. I found I was spending a lot of time interpreting what was going on rather than the design implementation process itself. 2. unless some clown thought conditional tail recursion was super awesome for the next guy. 3. All code is terrible, but some of it is useful... and if it is only useful to a few than it fails as a language. Keep in mind I learned on an RPN machine, so understand the sirens song lisp sings. ;)
- aidenn0 4y ago
  RE: 2 Tail recursion is non-idiomatic in Common Lisp; both because the standard does not guarantee tail-call elimination (as opposed to, say, Scheme) and because dynamic-binding, which is idiomatic in Common Lisp reduces the number of calls that are in a tail position. Also, tail-recursion is entirely divorced from syntax; perhaps you meant semantics? For example GCC will optimize tail calls in a rather broad number of contexts.
  - Joel_Mckay 4y ago
    If I recall correctly, some Lisp dialects had a super character that world close n open parentheses left open. You may have confused interesting with useful... Have a nice say ;)
- ortsan 4y ago
  1. In an average project Lisp would rank fairly high for me. In fact for making meaningful changes in an average quality large code base I'd rank it at the top, my order being (best first): Lisp, C, Java, C++, Python It all depends, e.g., C++ would rank higher in a very high quality code base.