4 ms·

Is this really about syntax? I think this is about homoiconicity. But homoiconicity is NOT the same thing as parenthesis, (or brackets as here)! Homoiconicity i

Is this really about syntax? I think this is about homoiconicity. But homoiconicity is NOT the same thing as parenthesis, (or brackets as here)! Homoiconicity is not a (concrete) syntax issue, it's an AST and semantics issue in my view. Why are we so hung up on the superficial details of the syntax. Can't we just have an AST spec with bijective mappings between different human presentations? Editors already do color coding for us and people use different fonts for their code, but flamewars about what colors and fonts are quite rare. I don't see this as anything fundamentally different. Is it somehow difficult to accept that different syntax may map to identical AST? Lisp is intentionally syntactically very close to its AST and I find this elegant. But why are we so hung up that the human interface for this has to be parens? Are people confused somehow that wanting to use different syntax means they want to change the language? Even if it no way forces people not to use parens if they want. Can't "the language" just be the AST? Am I overlooking something? I find this to be an almost trivial solution to many many neverending flamewars. I personally don't like parens because I want computer to do what it does best, which is doing routine churn like matching up parens. I don't mind if somebody else wants to see the parens. Why should I mind? The computer doesn't care at all. Multiple people could edit the very same code, one with parens, one with brackets and one without either (e.g. significant indentation). The EMACS solution is paredit or something where the editor tracks the parens. But why do these have to be there at all if the computer already knows how to track them? For me this is almost identical issue to C-family semicolons, tabs-vs-spaces indentation, formatting guidelines, the Guido colon, significant whitespace etc. Is this some authority or status or tribal thing or something? Or cultural lag from moveable type era? I don't get it. Why people find it so important how other people use want to see the superficial syntax? It's like having strong opinions how other people should paint the interiors of their house to me. Or is there some mix-up between form and function and we have different understandings where the separation goes? BTW, I recall seeing this post before, but it's not dated. As per wayback machine this has been published in 2020, and seemingly just has "repost=true" GET-variable for "dupe-busting(?)". Shouldn't this be marked as (2020) in the title?

klyrs 5y ago
I do metaprogramming in quite a few languages -- Python is the worst, and lisp is the best (and I've got literally thousands of times more experience with python). To me, homoiconicity is huge -- especially the comma and backtick operators make it a breeze. If you don't metaprogram, maybe you don't care -- but if you care at all about performance, a tiny collection of features it enables a whole new programming paradigm. Contrast this to Python. The best feature is f-strings, which approaches the ease of backtick/comma. But the lack of homoiconicity means you can't just jam a bunch of statements in a list -- for crap's sake, indentation makes everything a pain.
- jampekka 5y ago
  I fail to see the connection to syntax-vs-homoiconicity here. Python is definitely not the worst, e.g. in C you have maybe some preprocessor hacks. Python metaprogramming is also usually on "dynamic level" and a bit difficult to compare to macros as in e.g. Lisp. I fail to see the connection with f-strings to lack of homoiconicity, let alone indentation. I'm also a bit amazed why people see indentation as painful, don't you indent your code if the indentation is not significant?
  - kazinator 5y ago
    > don't you indent your code if the indentation is not significant? Well, not you; your editor does it for you.
    - jampekka 5y ago
      In vim I tend to use the "dumb-smart-indentation" that just keeps the same indentation for any new line. Seems to work fine for my purposes, just tab for new level and a backspace after to get back to the previous level. Although vim trying to be too smart about this nowadays, and tends to try to often just screw this up with some constantly braking magic.
pshc 5y ago
You make a good point. We ought to be working in AST-land rather than spending time arguing about delimiters. It's legacy and it's a classic example of the bikeshed effect. That being said, it's still an open problem to develop an ergonomic AST editor... I do want to see it.
- moonchild 5y ago
  S-edit. Or, more recently, hazel.
  - jmiskovic 5y ago
    I could not find way to run s-edit. Hazel seems to be web-only combination of programming language, runtime environment and novel editor. Thank you for these examples. There is also Anarres, a structured editor for Fennel (which is Clojure-like for Lua). Anyone knows of more?
    - moonchild 5y ago
      > s-edit https://interlisp.org/ https://interlisp.org/ shouldn't be hard > more https://github.com/disconcision/fructure https://github.com/disconcision/fructure Partly inspired by hazel, less active but probably a more broadly appealing language.
- jampekka 5y ago
  Why does AST need a specific editor? Just pick what you want. If you like parens, just use parens. I'd prefer to just specify the tree with significant indentation. These would be just files.
  - pshc 5y ago
    I want to work at the graph level, not the text level. My belief is that we could avoid a lot of artificial complexity and yak shaving around parsers, name resolution, and particularly collaboration/version control if we worked at this higher level.
smw 5y ago
The point jangid made above about being able to specify part of the program with only one character makes a significant difference: What I like about Lisp's syntax is that the cursor (point) is always in a complete Lisp program. You move up one set of parenthesis, again a complete program. Move up further .... till you reach the top (file-level). So this gives good opportunity to Editor makers. Compile "this" level, 1-level-up, 2-level-up and so on. In an editor you can always check your program while coding.
- jampekka 5y ago
  Why would this need parens? Many other ways to textually represent nested lists.

klyrs 5y ago

I do metaprogramming in quite a few languages -- Python is the worst, and lisp is the best (and I've got literally thousands of times more experience with python). To me, homoiconicity is huge -- especially the comma and backtick operators make it a breeze. If you don't metaprogram, maybe you don't care -- but if you care at all about performance, a tiny collection of features it enables a whole new programming paradigm. Contrast this to Python. The best feature is f-strings, which approaches the ease of backtick/comma. But the lack of homoiconicity means you can't just jam a bunch of statements in a list -- for crap's sake, indentation makes everything a pain.

jampekka 5y ago
I fail to see the connection to syntax-vs-homoiconicity here. Python is definitely not the worst, e.g. in C you have maybe some preprocessor hacks. Python metaprogramming is also usually on "dynamic level" and a bit difficult to compare to macros as in e.g. Lisp. I fail to see the connection with f-strings to lack of homoiconicity, let alone indentation. I'm also a bit amazed why people see indentation as painful, don't you indent your code if the indentation is not significant?
- kazinator 5y ago
  > don't you indent your code if the indentation is not significant? Well, not you; your editor does it for you.
  - jampekka 5y ago
    In vim I tend to use the "dumb-smart-indentation" that just keeps the same indentation for any new line. Seems to work fine for my purposes, just tab for new level and a backspace after to get back to the previous level. Although vim trying to be too smart about this nowadays, and tends to try to often just screw this up with some constantly braking magic.

pshc 5y ago

You make a good point. We ought to be working in AST-land rather than spending time arguing about delimiters. It's legacy and it's a classic example of the bikeshed effect. That being said, it's still an open problem to develop an ergonomic AST editor... I do want to see it.

moonchild 5y ago
S-edit. Or, more recently, hazel.
- jmiskovic 5y ago
  I could not find way to run s-edit. Hazel seems to be web-only combination of programming language, runtime environment and novel editor. Thank you for these examples. There is also Anarres, a structured editor for Fennel (which is Clojure-like for Lua). Anyone knows of more?
  - moonchild 5y ago
    > s-edit https://interlisp.org/ https://interlisp.org/ shouldn't be hard > more https://github.com/disconcision/fructure https://github.com/disconcision/fructure Partly inspired by hazel, less active but probably a more broadly appealing language.
jampekka 5y ago
Why does AST need a specific editor? Just pick what you want. If you like parens, just use parens. I'd prefer to just specify the tree with significant indentation. These would be just files.
- pshc 5y ago
  I want to work at the graph level, not the text level. My belief is that we could avoid a lot of artificial complexity and yak shaving around parsers, name resolution, and particularly collaboration/version control if we worked at this higher level.

smw 5y ago

The point jangid made above about being able to specify part of the program with only one character makes a significant difference: What I like about Lisp's syntax is that the cursor (point) is always in a complete Lisp program. You move up one set of parenthesis, again a complete program. Move up further .... till you reach the top (file-level). So this gives good opportunity to Editor makers. Compile "this" level, 1-level-up, 2-level-up and so on. In an editor you can always check your program while coding.

jampekka 5y ago
Why would this need parens? Many other ways to textually represent nested lists.